Ticket Server Performance Evaluation Using a Hybrid Simulation Approach

A ticket server architecture was proposed in [1] and [2] to issue tickets to ensure access to communications resources in crisis situations. End users interact directly with servers using intelligent agents that use an agent communication language. Here a hybrid simulation approach is used to assess ticket server performance requirements and network administrative overhead. The negotiation interaction between users and servers is implemented in a prototype. Network and ticket server performance are modeled using prototype results combined with analytical techniques for networks of queues. For two scenarios to simulate a hurricane event and an office building bombing event, ticket server performance requirements, network overhead, and connection setup delays were not found to be prohibitive. INTRODUCTION Modern broadband networks are designed to integrate all types of multimedia traffic. More importantly, however, they are designed to integrate and support the activities of all types of users. As networks become more and more useful to society, new types of users and user applications emerge. One user type of particular interest is the National Security/Emergency Preparedness (NS/EP) user. For such a user, prioritized access to network resources is vital, especially in times of response to natural or man-made disasters. This is because network facilities are commonly damaged and network demand frequently exceeds available resources [3]. In [1], a ticket server architecture was proposed to manage priority network activities. This architecture is illustrated in Figure 1. Users interact directly with regionally distributed ticket servers to request importance tickets that can be presented to generic network manager agents along with priority requests for network resources. These ticket servers maintain a model of the dynamic crisis context of the network and issue tickets according to a user's identity, organization, and need in the current This work was partially supported by the Madison and Lila Self Graduate Fellowship at the University of Kansas context. Ticket servers maintain this context model through coordination with local, regional, and national disaster control centers. This architecture supplements Internet Engineering Task Force (IETF) work on policy frameworks and directory enabled networks [4, 5] by providing a dynamically adaptive mechanism for prioritizing user traffic. In addition to these dynamic models of the network context, this architecture also provides users with great flexibility in negotiating for importance tickets. Users are able to request tickets directly, find out why tickets were not granted, update information, provide authentication resources to verify information they have provided, and even request that the server reconsider its view of the current context to match the user's view of that context. It is of great benefit to users, especially in tense conditions caused by a crisis, to have these capabilities. Intelligent agent technology and agent communication languages (e.g., the Knowledge Query and Manipulation Language, KQML [6]) are used to provide automated mechanisms that facilitate this interaction for the user. Several important performance issues must be considered with such an architecture. Interaction with ticket servers should not cause prohibitively long connection setup times, ticket server performance requirements must be reasonable, and excessive amounts of network overhead traffic must not be generated. This paper will show that these issues are not significant enough to prevent a successful implementation of the architecture, especially in light of the benefits such an architecture would provide. A quantitative performance analysis of this architecture was conducted using a useful approach that combined system prototyping and analytical network End User Network Manager Agent Network Manager Agent End User Authentication Resources Local, Regional, and National Disaster Control Centers Importance Ticket Servers Figure 1. Connection Importance Administration Architecture queueing analysis. This methodology was then used to simulate a hurricane event and an office building bombing event similar to the Alfred P. Murrah Federal Building Bombing in Oklahoma City in 1995 [7]. SYSTEM PROTOTYPE DESIGN Since users interact and negotiate with ticket servers using intelligent agents and an agent communication language, the first objective of this research was to create a system prototype to imitate these interactions. User and ticket server processes were created using Java Agent Template, Lite (JATLite) [8] that provides extensions to the Java programming language to support agent communication using KQML [6]. To provide intelligent agent capabilities, the Java Expert System Shell (JESS) [9] was used. This provided a rule-based expert system shell for user agents to generate requests for tickets and respond to responses to those requests. JESS was also used for server processes to respond to requests for tickets based on the current dynamic context and respond to user requests to renegotiate tickets. Ticket server processes also implemented rudimentary mechanisms for guarding against harmful user behaviors. One example was a mechanism for ending a negotiation session once it was unlikely that a user's further interaction would significantly improve a ticket. If not controlled, such user behavior could generate excessive unnecessary load on ticket servers. The purpose of the prototype was to characterize the negotiation process for a particular profile. A profile was defined as the interaction of a user with a ticket server in a certain context. A series of profiles could then be combined into a scenario to observe the negotiation process timeline as context changed. Figure 2 shows the overall design of the user and server processes for the prototype. The user process consisted of the User Negotiator that performed the negotiation activity for the user and generated KQML communication. A profile generator was used to start a particular negotiation session for a particular profile. The Importance Ticket Server process was modeled as a combination of six modules. Each module performed a distinct function and could process a certain number of requests per second. By explicitly identifying each of these modules, we were able to assess the performance of each module as a queueing system. In the next section, we show how these modules were combined to find the performance of the server as a whole. The black triangles shown at each module were used to assess the load on each module by recording the total number of requests per negotiation session that entered each module. These total numbers of requests were stored in variables st, sy, si, sd, sv, sm, and sg respectively. A brief description of each module in the ticket server is as follows. • Recognizer – Takes a user message and retrieves a session record about an ongoing ticket server session for that user. • Information Module – Processes messages where users request information to be stored in their session record or ask about the information in their record. • Decider – An expert system that makes the decision about the value of a ticket to issue based on the context status maintained by the Modeler. • Verifier – Verifies information provided by the user by contacting references given by the user or checking the validity of verification information provided directly by the user. • Modeler – Models the dynamic context in which the network is operating. This model can be updated manually by human experts, automatically in coordination with disaster control centers, or in response to information provided by a user. For the purpose of the prototype, it was assumed that the context was predefined in the profile for a particular negotiation session. • Negotiator – Once a request has been processed, the Negotiator decides how a subsequent request for this session should be handled. It may decide to end the session or allow the session to continue. PERFORMANCE ANALYSIS APPROACH Once the total number of messages per session that enter each module for a particular profile are recorded, a queueing network model can be used determine the overall performance of the server in the presence of many requests from different types of users. When combined with the arrival process of requests for new sessions from particular profiles, the overall arrival rate to each module can be Profile Generator User Negotiator KQML Communication Negotiator si st Importance Ticket Server Deny Request sy Verifier Decider Information Modeler Recognizer